Hey, it's yet 
another 
slideshow! 


(how surprising!) 



FluidSynth overview 



Rendered samples 




















How FluidSynth works 


SF2 Metadata SF2 Sample data 


> i 


MIDI processing: 

► Voices ► 

Audio processing: 

A Presets, tuning, 

Interpolation, 

gain, etc 


filters, etc 


a 

Rendered samples 






Use cases 


Live playing 

MIDI file player 

MIDI file Tenderer 

...but mostly: 

Embedded as an 
engine in other 
applications 



QSynth 


















































jOrgan 


fluidsynth-example -jOrgan 3.12.2 

File Edit View Help 






































SWAM I 











































































Use cases and requirements 


• Live playing • Low latency 

• MIDI file player • High performance 

• MIDI file Tenderer • Introspection 

...but mostly: • Configurability 

• Embedded as an 
engine in other 
applications 



The impossible problem 


1. Load a soundfont from disk 

2. Select a preset 

3. Start a note 

4. Render a block of audio 

And...be done within half a millisecond, or we'll 
get an underrun! 



Threads 


Audio driver thread: Render blocks 


Shell thread: load new SF2 file 
MIDI thread: input from keyboard 

GUI thread: Set reverb width 


FluidSynth core 




How we did it before 1.1.0 


(this page intentionally left blank) 



Okay, that was a little mean, but. 


int fluid_synth_noteoff(fluid_synth_t* synth, int 
chan, int key) 

{ 

inti; 

int status = FLUID FAILED; 

/* fluid_mutex_lock(synth->busy); A * Don't 
interfere with the audio thread *V 7 
/* fluid_mutex_unlock(synth->busy); V 

for (i = 0; i < synth->polyphony; i++) { 



Timing sources 


• The system timer 

• Based on the CPU's system clock 

• Problem 1\ Slow rendering 

• Problem 2: Worse timing with large buffer sizes - 
AKA the ’’drunk drummer” 

• The sample timer 

• Based on written audio data 

• Problem : signaling / communication 



1.1.0 architecture 


MIDI thread: input from keyboard 



GUI thread: Set reverb width 
































































































































































We were doing great, until... 


From: Rui Nuno Capela 

houston, we have a problem, 
i am sorry to chime in this late, but qsynth won't 
support this fluidsynth release. 

/.../ 

qsynth behaves very badly, inconsistently and 
troublesome against 1.1.0. 
everything just feels broken. 



Problems with 1.1.0 


Not getting what you're setting 

• Workaround: atomic stuff 

More to do for the audio thread 

• Workaround: move time intensive stuff to before the 
queue 

Reordering issues 

• Partially because of the two previous workarounds 



1.1.2 architecture 


GUI thread: Set reverb width 

MIDI thread: input from keyboard 
Shell thread: load new SF2 file 


"a 

Mutex & GC A 


Voice changes queue 


FluidSynth core: 
MIDI processing 




Audio driver thread: 
Render blocks 

t 

FluidSynth core: 
Audio rendering 



























































The sample timer problem 






























































Sample timer: proposed solution 


GUI thread: Set reverb width 

v 

MIDI thread: input from keyboard 
Shell thread: load new SF2 file 

\ \ 

Voice changes queues 


\ _3_ 

Mutex & GC 

FluidSynth core: 
MIDI processing 


Audio driver thread: 
Render blocks 


FluidSynth core: 
Audio rendering 


Midi player thread: 

... J 


Load files etc 


oemapnore 



































































































































































Synchronous MIDI and audio 


So far, JACK MIDI and JACK audio is the only 
known combination that causes this problem 

Solution could be to queue MIDI events to lower 
priority thread 


• ...unless we're ’’freewheeling” 



More introspection 


MIDI engine cannot know state of voices 
Wanted for voice overflow situations 
Wanted for some editors and players 

• Could be solved by audio thread writing down state 
data after every block, then atomically exchanging 
pointers 



Questions? 


Ask them now or forever email 
fluid-dev@nongnu-org 



